前言

如同之前的所有系列一樣，重要事件也有大事件和小事件。而這篇文章將分享一篇小事件，也就是資料庫搬家的工作。

背景

背景故事是，我們的資料庫使用了某一個即將要 EOL 的 RDS MySQL 版本。在受到 EOL 通知並決定升級的時候，我們決定順便一起改用 AWS 自家推出的 Aurora MySQL Compatible 資料庫。因此才有了這次的搬家(migration)工作。

資料庫的搬遷本身具備一定風險，再加上資料庫一般來說，會是一個服務中最重要的資源。因此這原本應該要算是一件大型工作，但因為我們從頭到尾都還是使用 MySQL ，因此真正需要研究和執行的工作並沒有那麼多，最後才會被我歸類為是小型事件。

初步研究與盤點

首先，在正式搬家之前，我們要先確認搬家的各個步驟。一般來說，因為是完全相同的資料庫，因此不需要有資料轉移或考慮相容性之類的問題，我們所需要思考的，就只有如何將資料完整地搬運過去而已。另外，因為資料庫的搬遷至少會需要後端切換連線 endpoint 的關係，系統的暫時斷線似乎無法避免，因此我們也決定直接進入維護模式以避免意外發生。

我們可以先初步將步驟羅列成以下：

1. 進入維護模式
2. 資料庫搬遷作業
3. 後端切換 endpoint 到新的資料庫，並重啟連線
4. 確認服務正常
5. 離開維護模式

交付給筆者研究的，就是第2步中有關資料庫搬遷作業的方式。

搬家方式

首先，最簡單的當然就是將資料完整備份出來(snapshot)後，將其還原到新的 Aurora 資料庫上。如下圖：

這個作業方式將面臨以下兩個明顯的限制：

• 資料備份的行動只能在進入維護模式後才開始
• 資料的搬遷將花費大量時間，影響其它也要在維護模式中進行的工作

如果沒有其它好方法，其實上面提到的問題也是無可厚非，畢竟這本來就是資料庫搬遷會面臨到的過程。不過，可能因為 AWS 也在強力推荐 Aurora 的關係，因此經過研究，我們發現有另一個更方便的搬遷方式。請見下圖：

大致上，我們先在原本的 RDS MySQL 機器上啟動一個 Aurora MySQL Instance，所有在舊 RDS 上的資料，就都會開始同步到新的 Aurora 機器上。而搬家當天，我們要做的事情就是將 Aurora 那台機器給提升(promote)成一個新的 Aurora Cluster。可以參考AWS文件：Migrating data from a MySQL DB instance to an Amazon Aurora MySQL DB cluster by using an Aurora read replica - Amazon Aurora。

這顯然直接解決了我們前面所提到的問題，帶來最大的好處就會是節省了搬家所需要的時間。因為資料的搬遷本身是最花時間的，因此如果能夠在正式搬家前就完成這件事情，但又不會影響到資料的同步問題，那就會是非常理想的解決方案。

以下是我在測試時的實驗截圖：

可以由上圖看到，我建立了一個RDS MySQL的機器，並在其下又建立了Aurora MySQL Cluster並附帶一個機器。請再見下圖：

藉由在主控台上直接點選 promote 的方式，我們就可以將該 Aurora 機器提升為另一個 cluster。讀者應該可以在圖中看到，其實上面有另一組 Aurora MySQL 的機器，正是前一組測試機成功提升為 cluster 的結果。

後記

藉由上述方式，我們最後也成功完成了資料庫的搬家。而這件事情本身因為會進入維護模式，因此筆者也同時在第一次使用改良後的維護模式工具。不得不說，筆者當下只能打從心裡祈禱不要出任何意外，如果出了什麼意外，現在可能就無法悠然自得地把這篇文章產出來了吧。

當初在準備 AWS 相關證照的時候，其實有準備過與 migration 相關的主題。雖然準備的當下都不清楚到底未來什麼時候會用到，但也沒有想到，居然這麼快就可以在這裡派上用場。

從另一個角度來看，因應現在普遍上雲的趨勢，SRE 對於雲端技術的掌控可以說是越來越重要了。如果讀者對這一塊感興趣，筆者也會在最後一篇中向各位分享筆者認為可以準備的方向。

下一篇，將進入另一個對敝公司可能可以說是維運面最重大的技術轉折點之一，也就是 OpsWorks 的 EOL。